Software-Defined Networks as Databases

In software-defined networks (SDN), the separation of the control and data-plane moves the concurrency control from the data-plane to a separate, now logically centralized controller program. As a result, despite its intention to simplify programming, the separation forces the programmer to deal with a spectrum of concurrent events (e.g. execution of controller programs, in-flight packets), a task that is notoriously challenging and error-prone. It is not even clear what concurrency problems the programmer shall account for. Although early stage works propose specific correctness conditions and point solutions[4, 1], a comprehensive study is still lacking. Most existing work focuses on the concurrency problem we call atomicity1, which concerns one single networkwide update transaction. We use network-wide transaction (or transaction) to refer to a logical network operation that consists of potentially multiple switch-level updates. An atomicity failure scenario is shown in the figure (the red transaction spanning over switches 1, 2, 4) when in-flight packets during the transaction are processed by a mixture of switches with rules before or after the transaction. In addition to atomicity, we identify concurrency problems arising from multiple transactions, which we call the consistency and isolation. To the best of our knowledge, they are not addressed in existing works. Section 3 will connect atomicity, consistency, and isolation to the well-studied ACID transactional semantics in databases literature [3]. Here, we introduce their intuition by examples: – Consistency. Consider a load balancing controller program that instructs a switch (4) to forward a flow through a randomly yet uniquely chosen server (4’s next-hop set to either 3 or 5). Two packets of the same flow that arrive in a short window could trigger two concurrent updates (the red transactions of solid and dashed intervals), causing two conflicting rules that forward the flow through different next-hops, thus violating consistency. Such consistency is not automatically enforced in today’s SDN subsystem, but is manually handled by programmers. – Isolation. Interleaving concurrent transactions may further complicate the problem (the red and green transactions by C1, C2) — the interleaving could leave the switches to apply updates in different orders. If updates are not commutative (e.g. updates to firewall and load-balancer), it can lead to inconsistent processing of flows. Note that interleaving transactions is desirable even with one single controller e.g. an on-going transaction in a data-center involving thousands of switch updates should not block incoming ones.